multifrequency monitor - перевод на Английский
![[[Apple II]] [[6502]] machine code monitor](https://commons.wikimedia.org/wiki/Special:FilePath/Apple II Monitor.png?width=200 "[[Apple II]] [[6502]] machine code monitor")
![Massachusetts Avenue]] in [[Boston]]](https://commons.wikimedia.org/wiki/Special:FilePath/2006 ChristianScienceMonitor building Boston 2594437787.jpg?width=200 "Massachusetts Avenue]] in [[Boston]]")
![aspect ratio]].](https://commons.wikimedia.org/wiki/Special:FilePath/Computer screen dimensions.png?width=200 "aspect ratio]].")
![[[Eizo ColorEdge]] monitor with screen hood](https://commons.wikimedia.org/wiki/Special:FilePath/Monitor-Eizo-CG277-BK-27inches-01.jpg?width=200 "[[Eizo ColorEdge]] monitor with screen hood")
.jpg?width=200 "Hydraulic arm monitor stand, connected via VESA mount holes")
Определение
Википедия
A machine code monitor (a.k.a. machine language monitor) is software that allows a user to enter commands to view and change memory locations on a computer, with options to load and save memory contents from/to secondary storage. Some full-featured machine code monitors provide detailed control ("single-stepping") of the execution of machine language programs (much like a debugger), and include absolute-address code assembly and disassembly capabilities.
Motorola published the MIKBUG ROM monitor for the 6800 in 1973 and the BUFFALO ROM monitor for the 68HC11.
Machine code monitors became popular during the home computer era of the 1970s and 1980s and were sometimes available as resident firmware in some computers (e.g., the built-in monitors in the Commodore 128, Heathkit H89 and Zenith laptops). Often, computer manufacturers rely on their ROM-resident monitors to permit users to reconfigure their computers following installation of upgrade hardware, such as expanded main memory, additional disk drives, or different video displays.
It was not unheard of to perform all of one's programming in a monitor in lieu of a full-fledged symbolic assembler. Even after full-featured assemblers became readily available, a machine code monitor was indispensable for debugging programs. The usual technique was to set break points in the code undergoing testing (e.g., with a BRK instruction in 6502 assembly language) and start the program. When the microprocessor encountered a break point, the test program would be interrupted and control would be transferred to the machine code monitor. Typically, this would trigger a register dump and then the monitor would await programmer input. Activities at this point might include examining memory contents, patching code and/or perhaps altering the processor registers prior to restarting the test program.
The general decline of scratch-written assembly language software has made the use of a machine code monitor somewhat of a lost art. In most systems where higher-level languages are employed, debuggers are used to present a more abstract and friendly view of what is happening within a program. However, the use of machine code monitors persists, especially in the area of hobby-built computers.
